Systemübergreifende Software-Architektur: Erfahrungen und Thesen

Die Prinzipien der Software-Architektur sind wohlbekannt und akzeptiert: Trennung der Zuständigkeiten, Denken in Komponenten und Schnittstellen, durchgängige Behandlung von Fehlern und Ausnahmen und noch ein paar andere. Trotzdem wäre es vermessen zu behaupten, dass wir die Architektur eines einzelnen großen Systems beherrschen. Dieser Vortrag befasst sich mit dem noch schwierigeren Problem der systemübergreifenden Software-Architektur: Wie kooperieren Systeme, die verschiedene Teams mit unterschiedlicher Technik unabhängig voneinander gebaut haben? Dabei sind u.a. folgende Fragen zu beantworten: Sind die klassischen Regeln der Software-Architektur weiterhin gültig? Sind sie ausreichend oder brauchen wir neue Richtlinien? Sind moderne Web-basierte Techniken hilfreich oder hinderlich? 1. Software-Architektur im Großen: ein großes System Die Grundlagen der Software-Architektur (z.B. [P78]) sind auf jeder Ebene das Denken in Komponenten und Schnittstellen, die Trennung der Zuständigkeiten und die Berücksichtigung von Notfällen. Die Komponente (nicht die Klasse) ist die wesentliche Einheit des Entwurfs, der Planung und der Integration [BCK03]. Schnittstellen sind abstrakte Dienste, deren Syntax, Semantik und nichtfunktionalen Eigenschaften im Sinn eines Vertrags verbindlich festgelegt sind. Komponenten kommunizieren grundsätzlich über Schnittstellen, niemals direkt. So läuft jede Komponenten in einem durch Schnittstellen definierten Kontext; benachbarte Komponenten, die diese Schnittstellen implementieren, sind austauschbar. Bei der Trennung der Zuständigkeiten hat sich in der Praxis die Trennung von Anwendungssoftware (A-Software) und Techniksoftware (T-Software) als besonders nützlich herausgestellt [S03].